[wasm] improve startup #72275
Merged
[wasm] improve startup #72275
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pavelsavara
added
arch-wasm
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
|
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I tested with current and also future! Blazor |
This comment was marked as outdated.
This comment was marked as outdated.
pavelsavara
force-pushed
the
wasm_improve_startup
branch
from
8a1057f to
d319c22
Compare
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
pavelsavara
force-pushed
the
wasm_improve_startup
branch
from
1703991 to
d839ef8
Compare
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
This is the startup sequence for non-blazor |
pavelsavara
force-pushed
the
wasm_improve_startup
branch
from
657f65b to
d2884fb
Compare
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
pavelsavara
force-pushed
the
wasm_improve_startup
branch
from
d2884fb to
2050175
Compare
|
This is startup sequence with updated blazor |
|
/azp run runtime-wasm |
# Conflicts: # src/mono/wasm/runtime/diagnostics.ts # src/mono/wasm/runtime/dotnet.d.ts # src/mono/wasm/runtime/pthreads/worker/index.ts # src/mono/wasm/runtime/startup.ts # src/mono/wasm/runtime/types.ts
|
Threaded sample isn't happy after the merge. I'm investigating repro steps:
|
|
Update: the fix helps, but there is still a problem.
I think what's happening is that Which might be because |
|
Here's what our |
|
Ok, so the issue is in this function run(args) {
args = args || arguments_;
if (runDependencies > 0) {
return;
}
if (ENVIRONMENT_IS_PTHREAD) {
readyPromiseResolve(Module);
initRuntime();
postMessage({
"cmd": "loaded"
});
return;
}
preRun();
if (runDependencies > 0) {
return;
}
function doRun() {
if (calledRun) return;
calledRun = true;
Module["calledRun"] = true;
if (ABORT) return;
initRuntime();
readyPromiseResolve(Module);
if (Module["onRuntimeInitialized"]) Module["onRuntimeInitialized"]();
postRun();
}
if (Module["setStatus"]) {
Module["setStatus"]("Running...");
setTimeout(function() {
setTimeout(function() {
Module["setStatus"]("");
}, 1);
doRun();
}, 1);
} else {
doRun();
}
}So when we do module.ready = module.ready.then(async () => {
// wait for previous stage
await afterPostRun.promise;
// - here we resolve the promise returned by createDotnetRuntime export
return exportedAPI;
// - any code after createDotnetRuntime is executed now
});Because nothing resolved Update it's less misleading to just return from module.ready = module.ready.then(async () => {
// wait for previous stage
// on pthread workers, postRun is never called, so there is nothing to wait for
if (!ENVIRONMENT_IS_PTHREAD) await afterPostRun.promise;
// - here we resolve the promise returned by createDotnetRuntime export
return exportedAPI;
// - any code after createDotnetRuntime is executed now
});With the above change, the diagnostics sample works for me. Maybe we should just return from |
|
As follow-up to this PR we should figure out what kind of JS initialization we want to do in pthread workers. the normal callbacks don't fire. i'm not sure if that's ok or if it's leaving some part of our JS state incorrect. |
|
@lambdageek there is alredy condition in Which is I guess some different issue. If the build is green, I will merge as is and we will continue in follow-up PRs.
|
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I noticed on the screenshot that the |
|
@lambdageek when I rebuild with
|
|
This is release version |
That's an asssert that we resumed a thread more times than we suspended it. Probably not due to this PR. |
lambdageek
reviewed
Jul 26, 2022
Comment on lines
-356
to
+316
| configure_emscripten_startup(module, exportedAPI); | ||
|
|
||
| if (ENVIRONMENT_IS_WORKER) { | ||
| // HACK: Emscripten's dotnet.worker.js expects the exports of dotnet.js module to be Module object | ||
| // until we have our own fix for dotnet.worker.js file | ||
| // we also skip all emscripten startup event and configuration of worker's JS state | ||
| // note that emscripten events are not firing either | ||
| return <any>exportedAPI.Module; | ||
| } | ||
|
|
||
| configure_emscripten_startup(module, exportedAPI); | ||
|
|
|
There is well known There is also timeout on V8+windows edit: maybe this PR surfaced the #72880 |
10 tasks
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
streaming wasm instantiation, more parallel download of DLLs
and other goodnes seen in Blazor
downloadResource?: (request: ResourceRequest) => LoadingResourceallows Blazor to delegate the details to runtime while keeping the caching responsibility.config.assetscould now haveresolvedUrlandpendingresponse. That's blazor could tell us what to load and also provide pending cache promise.mono_wasm_pre_init_esentialalso in Blazor loader. This will fix subtle crypto for them.mono_wasm_after_runtime_initializedalso in Blazor loader. This would domono_wasm_load_runtime,,mono_wasm_runtime_readyandbindings_lazy_initfor them. This will enable new[JSImport]for blazor.locateFileis now used for all assets includingmono-config.json. I also fixedscriptDirectorydetection on all but v8+CJS. Therefore apps could be executed from different folder than isdotnet.jslocation. Credits to @yamachuinit_cryptoalso on blazor startup sequenceContributes to #70892
Contributes to #72810